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Abstract 

In this paper we present a set of tests aimed at 
evaluating the responsiveness of a BeagleBone Black 
board in real-time interactive audio applications. 
The default Angstrom Linux distribution was tested 
without modifying the underlying kernel. Latency 
measurements and audio quality were compared 
across the combination of different audio interfaces 
and audio synthesis models. Data analysis shows 
that the board is generally characterised by a re¬ 
markably high responsiveness; most of the tested 
configurations are affected by less than 7ms of la¬ 
tency and under-run activity proved to be contained 
using the correct optimisation techniques. 
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1 Introduction 

Research in Music Technology and, in partic¬ 
ular, on Digital Musical Instruments (DMIs) 
is strongly connected to the field of Human- 
Computer Interaction (HCI). Following the 
trend of many other disciplines involving HCI, 
like Ubiquitous Computing [Kranz et ah, 2009 
and Augmented Reali ty f Langlotz et ah, 2012, 

Ellsworth and Johnson, 2013J7 DMI research 

has recently started capitalising on portable and 
embedded systems rather than on general pur¬ 
pose architectures. After many years of com¬ 
plete synergy, musical instruments are increas¬ 
ingly abandoning the laptop/desktop computer 
in favour of onboard audio processing, leaving 


an important mark in both aca demia |Berdahl 


et al., 2013[ Oh et al., 2010; Baclawski and 

Jackowski, 20L 
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This is due to the fact that DMIs require a 
specific set of design features to provide the user 
(i.e., a performer, a composer, a casual player) 


1 http://monome.org/aleph/ 
2 http://line6.com/tcddk/ 

3 http://hoxtonowl.com/ 


with a musical experience not too far from the 
one typical of acoustic and electric instruments 
|Berdahl and Ju, 2011 . This natural compari¬ 
son with well known “devices”, such as piano 
and guitar, underlines qualities like reconfig¬ 
urability, independence/autonomy and high re¬ 
sponsiveness, which can be assured only on a 
dedicated system. 

As designers and developers of open source 
novel DMIs, we have decided to explore the 
promising and evolving world of embedded 
Linux technologies, focusing as starting point on 
the concept of responsiveness. The work here 
presented shows the result of a series of tests 
aimed at measuring the latency of a Beagle¬ 
Bone Blackboard (BBB), used as the core of a 
self-contained, open-source musical instrument. 
Different hardware and software configurations 
based on the same Linux kernel (v3.8.13) have 
been analysed under different CPU loads and 
levels of code optimisation. 

This work is part of a larger structured 
study, whose goal is to assess longevity, usabil¬ 
ity and reconfigurability of DMIs, compared to 
the standards of acoustic and electric musical 
instruments. 


2 Related Work 

In 2011 Berdahl et al. present ed the Satellite 
CCRMA [Berdahl and Ju, 2011 , a platform for 
teaching and practicing interaction design for 
diverse musical applications, completely based 
on embedded Linux. It runs on a BeagleBoarc0 
coupled with an Arduino Nank and a bread¬ 
board, to support the use of sensors and ac¬ 
tuators. Two years later, Berdahl et al. up¬ 
graded the platform enabling the compatibil¬ 
ity with more powerful boards, such as Rasp- 

4 http: //beagleboard. org/product s/beaglebone 0 / 
20black 
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berry PQ and BeagleBoard-x]V0, and expanded 
the range of possible applications including net¬ 
working capabilities and hardware-accelerated 
graphics [s |Berd ahl et ah, 20131. The project is 
based on a Fedora distribution with a custom 
low latency kernel. 

A good example of how new generation em¬ 
bedded Linux boards can be used to extend the 
capabilities of a musical instrument has been 
recentl y presen t ed by MacConnell et al. [M ac-| 
Connell et ah, 2013[. This work introduces 
a BBB-based open framework for autonomous 
music computing eschewing the use of the lap¬ 
top on stage. Some important features of em¬ 
bedded systems are here used to provide the in¬ 
struments designed using the framework with 
high degrees of autonomy and reconfigurabil¬ 
ity. Authors include also data regarding the 
latency of the system running Ubuntu 12.04. 
Since mainly FX-like processes are addressed, 
only the audio-throughput time is measured, 
under different system load configurations. Re¬ 
sults vary between 10 to 15 ms, according to the 
kind of filtering. 

The necessity of measuring the responsive¬ 
ness of computer-based systems is not recent 
at all, especially in the context of real-time op¬ 
erative systems. In 2002, Abeni et al. used 
a series of micro-benchmarks to identify major 
sources of latency in the Linux kernel |Abeni 
et al., 2002]. They also evaluated its effects 
on a time-sensitive application, in particular an 
audio/video player. Moving towards computer- 
based audio systems, it is worth mentioning the 
work by Wright et al. |Wright et al., 2004], in 
which the latency of MacOS, Red Hat Linux 
(with real-time kernel patches) and Windows 
XP are compared, both in an audio-throughput 
configuration and in an event audio-based con¬ 
figuration. The technique used to estimate 
the event audio latency consists of measuring 
the time delay between the sound produced by 
pressing a button on the keyboard and a sinu¬ 
soidal audio output triggered on the computer 
by pressing the button itself. 

3 System Configuration 

The tests presented throughout this work aim 
at the evaluation of the capabilities of a BBB- 
based system when used as development plat¬ 
form for DMIs. The chosen configuration in- 

‘ http://www.raspberrypi.org/ 

s http://beagleboard.org/Products/ 
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eludes most of the standard components re¬ 
quired to synthesise and control audio in real¬ 
time on a self-contained instrument (i.e., with¬ 
out the need of laptops and any additional ex¬ 
ternal devices). Details on each of these com¬ 
ponents are given in the following subsections. 

3.1 Board and OS 

The BBB is an embedded Linux board based 
on a 1GHz ARM Cortex-A8 processor. It is 
shipped with an embedded Angstrom Linux dis¬ 
tribution (v3.8), optimised to run on embedded 
architectures. This distro is meant to run gen¬ 
eral purpose applications and it is not specif¬ 
ically audio-oriented. Our first intent was to 
explore the capabilities of this default board 
configuration, without introducing any changes 
in the underlying kernel. We believe this ap¬ 
proach could be very useful for the community 
of embedded developers to have a clear outline 
of the built-in audio capabilities of the BBB, 
thus helping choose the right board. 

Although belonging to a new generation of 
compact and fully accessorised boards (e.g., 
HDMI, uSD card slot), the BBB does not na¬ 
tively provide any audio interfacing. To test 
the performances of this board in relation to 
high quality audio synthesis, two commercially 
available audio interfaces were chosen for com¬ 
parison; these were both configured for use with 
the board so as to provide real-time audio out¬ 
put. 
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Figure 1: The USB interface and the Audio 
Cape attached to the BeagleBone Black. 

3.2 Audio Interfaces 

We tested one USB interface and one Beagle- 
Bone expansion “cape” providing audio output. 

























This choice aimed at comparing the two most 
common solutions used by BBB users for gen¬ 
erating audio output. Figure [l] shows both the 
interfaces attached to the board. 

The first interface used is the Turtle Beach 
Amigo II USB Interfac^jThis device is bus- 
powered and USB 2.0 class-compliant.. Once 
attached, this device is automatically recog¬ 
nised as a new hardware interface, meaning that 
it simply requires being specified as the selected 
device for audio applications. This interface 
provides 2 stereo 3.5mm jack receptors, one for 
input the other for output. Only the latter has 
been used for our tests. 

The second interface used for our tests is 
the BeagleBone Audio Capj^j this device effec¬ 
tively acts as an extension to the BBB, it simply 
attaches to the top of the board to provide an 
audio interface. Audio data are exchanged to 
and from the BBB using an I2S connection. Un¬ 
like the USB interface, this device requires some 
manual configuration to be recognised as a plug¬ 
in hardware interface. The on-board HDMI au¬ 
dio virtual cape must be disabled so that the 
Audio Cape can be loaded by the firmware as 
the main audio device; this can be easily done 
by changing the uBoot parameters passed at 
boot-time. As the USB interface, this cape in¬ 
cludes a couple of stereo 3.5mm input/output 
jack receptors. 

3.3 Audio Synthesis 

Two different audio backend systems were de¬ 
veloped in C++ and cross-compiled to run on 
the ARM Cortex-A8 processor, one based on 
ALSA, the other based on JACK. ALSA and 
JACK implementations are currently adopted 
by a large number of Linux audio developers. 

The audio backend system based on ALSA 
(Advanced Linux Sound Architectural) essen¬ 
tially comprises an audio engine and a para¬ 
metric synthesizer. The synthesizer produces 
frame data; it is connected to the audio engine, 
which is responsible for collecting and trans¬ 
porting this frame data to the selected output 
device. 

The audio backend system based on JACK 
(Jack Audio Connection KiQ was similarly 
designed. A fundamental difference between 
these two APIs is that JACK uses a client-server 

9 www.turtlebeach.com 
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model between operating processes and output 
devices. For this reason, only a synthesizer class 
was designed to operate as the client process, 
while a standard JACK server acts as the audio 
engine for transport. In this configuration the 
server pulls audio from the client process every 
time it requires new output data, this is in stark 
contrast to the ALSA system whereby audio is 
pushed to the output devices. 

Concerning audio synthesis, both the synthe¬ 
sizers implemented in ALSA and JACK gener¬ 
ate simple sine waves based on reading from 
a wavetable. Both systems are configured to 
provide CD quality audio, (i.e., 16bit resolu¬ 
tion, 44.1KHz sample rate) and to run the au¬ 
dio thread at the maximum priority level using 
a real-time FIFO scheduling. 

A parallel control thread was included to 
manage user input through the keyboard and to 
have access to the general-purpose in/out pins 
(GPIO) read/write capabilities of the BBB. 

4 Performance Test 

The responsiveness and the audio quality of 
four different specific configurations were tested, 
combining the use of the 2 audio backends 
(ALSA an JACK) with the 2 audio devices 
(USB and Audio Cape). Responsiveness was 
evaluated considering the latency occurring be¬ 
tween the triggering of an audio task produc¬ 
ing a waveform and the actual output of the 
waveform through the audio interface; the as¬ 
sessment of audio quality was connected to the 
incidence of under-runs. 

The performances of each configuration were 
measured running the audio task in 3 distinct 
test scenarios. Each of these scenarios (de¬ 
scribed in the following subsection) involved 
testing different period and buffer size config¬ 
urations. As the focus of the test is concerned 
with very low latency, only the smallest possi¬ 
ble period and buffer sizes were examined. In 
addition, each measurement was repeated en¬ 
abling 3 different optimisation settings on the 
C++ cross-compiler (Linaro GCC 4.7 hosted on 
a x86_64 architecture), using the 01, 02 and 03 
flags. 

4.1 Test Scenarios 

The first scenario involved the generation of a 
simple monophonic tone. As mentioned in Sec¬ 
tion [3T2J a simple lookup table was used to gen¬ 
erate the frames for this tone. 

The second scenario consisted of creating the 
same monophonic tone as used in the first see- 



nario, however whilst a Top background pro¬ 
cess was active with a fast refresh rate (passing 
the command line argument “-d 0.1”) (but with 
standard priority). This scenario allowed for the 
efficiency of audio synthesis to be observed and 
measured whilst the system was under heavier 
load. 

The final test scenario was concerned with 
the generation of a more complex polyphonic 
tone; this was achieved through the summation 
of three harmonically related monophonic oscil¬ 
lators. The addition of these two extra tones 
was considered to be a suitably harder task to 
synthesise than the simple monophonic tone. It 
must be noted that no background process was 
executed during this scenario. 



Figure 2: The setup to measure latency when 
using the USB interface. 

4.2 Procedure 

The BBB was connected by USB; tests were 
performed over an ssh connection via BBB’s 
USB network connection. One of the board’s 
GPIOs was attached to the first input channel 
of an oscilloscope. The audio output was con¬ 
nected to the second channel of the oscilloscope. 
For the case of the USB interface, the complete 
setup is shown in Figure [2| 

In detail, the test procedure ran as follows. 
Upon starting one of the executables, the gener¬ 
ated system (ALSA or JACK) was programmed 
to initialise itself but then wait for user input 
(i.e. a keystroke) before beginning to fill the 
output buffers with frames. Once the keystroke 
signal was received across the serial connection, 
the first task of the system was to drive the 
GPIO connected to the oscilloscope from low to 
high. Only immediately after this the audio cy¬ 


cle could begin, outputting the signal into the 
oscilloscope. The oscilloscope was set to trigger 
a single display capture on both the channels 
upon the detection of a rising edge in the GPIO 
signal. The time distance between the GPIO 
rising edge in the display and the beginning 
of the captured audio output hence provided a 
measurement of the operational latency (Figure 
[3]) ; each measurement was repeated 5 times [as¬ 
suming that’s right] and an average value cal¬ 
culated. 


Figure 3: Examples of oscilloscope display cap¬ 
ture for scenarios 1 and 3. Latency is measured 
as the horizontal distance (time gap) between 
the GPIO signal rising edge (in yellow) and the 
start of the waveform (in light blue). 

It must be noted that the period and buffer 
sizes chosen were dependent upon both the sys¬ 
tem type and the target interface; configura¬ 
tions that worked well for one pair did not nec¬ 
essarily run well for another. The six smallest 
usable configurations were tested for each sys¬ 
tem and interface pair. 

In addition to measuring the output latency, 
the quality of the output audio was also ob¬ 
served; this observation relied upon noting the 
frequency of frame dropout (under-run activity) 
and visible distortion displayed on the oscillo¬ 
scope (if any). 

5 Results 

The reported measurements are here presented 
and discussed, first globally and then analysing 
more specific cases. Both latency and quality of 
the output (under-runs) are taken into account 
and the singular contributions are combined. 










5.1 Latency 

The latency results were highly consistent 
across trials: when using the USB audio in¬ 
terface with both ALSA and JACK systems 
(Fgures [4] and [6]) the maximum difference be¬ 
tween individual measurements generally only 
varied by one millisecond, with only few excep¬ 
tions; this was true regardless of the used opti¬ 
misation. Measurements concerning the Audio 
Cape (Figures [5] and [7]) were even more consis¬ 
tent than for the USB interface. Across the five 
measured latencies, measurements only varied 
by half of a millisecond, without exceptions. 

As expected, for all configurations, latency is 
directly related to buffer and period sizes. No 
significant, systematic latency differences were 
noted amongst the three optimisation settings. 

However, the choice of monophonic versus 
polyphonic synthesis and the system load in¬ 
troduce unexpected variations in the latency. 
These variations may reflect a delay in start¬ 
ing up the ALSA or JACK system, rather than 
a difference in steady-state latency once the au¬ 
dio rendering is running. Our test procedure 
toggles a GPIO pin and then immediately be¬ 
gins filling the audio buffers; it is possible that 
this initial startup produces an additional tran¬ 
sient delay compared to reacting to an event 
once audio is already running. In any case, the 
difference between test conditions is always less 
than 1ms. 
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Figure 4: ALSA latency measurements for the 
USB interface. 

ALSA - Audio Cape 
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Figure 5: ALSA latency measurements for the 
Audio Cape. 

It can be noted that, on both systems, the 
Audio Cape allows for smaller buffer and period 


JACK - USB Interface 
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Figure 6: JACK latency measurements for the 
USB interface. 

JACK - Audio Cape 
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Figure 7: JACK latency measurements for the 
Audio Cape. 


configurations. Unfortunately, the set of avail¬ 
able configurations varies between the 2 sys¬ 
tems, making impossible a direct performance 
comparison. For the only overlapping configu¬ 
ration (buffer 512 - period 32), JACK performed 
unexpectedly badly, showing a higher latency 
than configurations based on larger period sizes. 

Conversely, USB interface results extend on 
the same set of configurations for both ALSA 
and JACK, so that a quantitative comparison 
is here possible. For the smallest period size 
(i.e. 64 frames) the JACK system shows bet¬ 
ter or equal performances, while increasing the 
size ALSA proved remarkably more responsive. 
In particular, the last 3 cases listed in Figure [6] 
shows that JACK’S latency is almost the same 
and quite high, regardless of all the conditions, 
i.e. buffer/period sizes, test scenario and opti¬ 
misation level. 

5.2 Under-runs 

The test highlighted a certain incidence of 
under-runs, whose effects varied according to 
the chosen configuration. Generally, they oc¬ 
curred in particular when lowest buffer and pe¬ 
riod sizes were tested. Also the different opti¬ 
misation settings proved to strongly affect their 
incidence. 

5.2.1 ALSA 

Using ALSA on the USB interface, it was ob¬ 
served the occurrence of frame dropout issue 
only when the buffer and period were set to 
the minimum values (i.e. respectively 128 and 8 
frames). This was true across all the build qual- 



















































































ities of the system and for all of the scenarios. 
During the first scenario (pure tone) and third 
scenario (polyphonic tone) observed dropouts 
were not too severe, normally only being exhib¬ 
ited once or twice at the beginning of synthesis. 
The second scenario seemed to generate signif¬ 
icantly higher rates of frame dropout, leading 
to audible clicks. An interesting observation is 
that the 02 optimised versions of the system 
appeared to always exhibit the least amount of 
under-runs. 

In the case of the ALSA system using the Au¬ 
dio Cape, it was observed that frame dropout 
only occurred whilst using the smallest period 
size configurations (period size of 8), regardless 
of the buffer setting. Again this was true across 
all the build qualities of the system and all of the 
scenarios. The first and third scenario produced 
a very small amount of under-run activity, in¬ 
terestingly only for the first period and buffer 
size configuration tested. Similarly to the USB 
interface, these observed dropouts were very mi¬ 
nor, normally only being exhibited once or twice 
at the beginning of synthesis. In the second 
scenario the amount of frame dropout did in¬ 
crease slightly. Interestingly, this time the 03 
optimised versions exhibited the best improve¬ 
ments, almost completely preventing all under¬ 
runs. 

5.2.2 JACK 

Since in JACK the stream to the audio device is 
not managed by the client, under-runs can occur 
only not he server. In relation to the JACK sys¬ 
tem using the USB audio interface, most frame 
dropout issues observed occurred during the 
first size configurations (buffer 128 - period 16), 
the second one (buffer 128 - period 32) and the 
fourth one (buffer 256 - period 32). In regards to 
the first and third scenarios, the frame dropouts 
noted for the first period and buffer size con¬ 
figuration were very severe for the 01 and 02 
optimisations. The amount of under-run activ¬ 
ity for this configuration made it very difficult 
to gather any measurements for latency; some¬ 
times the JACK server would under-run con¬ 
tinuously without the client even being active. 
The 03 optimisation however did not experi¬ 
ence this problem for this configuration; under¬ 
runs were noted however were nowhere near as 
severe. In the case of the second scenario, far 
less dropouts were observed consistently across 
all build qualities, a surprising result. Again, 
03 optimisation proved to provide the best per¬ 
formance enhancement. 


In the case of the JACK system using the 
Audio Cape, it was noticed that the occurrence 
of frame dropout appeared more frequently for 
the first three period and buffer size config¬ 
urations. The first scenario produced a very 
small amount of under-run activity, in regards 
to all the three optimisations; only during the 
first scenario were any frame dropouts observed. 
The nature of these under-runs however was dif¬ 
ferent to those previously observed; during the 
synthesis the server ran smoothly, while under¬ 
runs were noted only after the client had been 
disconnected. It was observed during the sec¬ 
ond scenario that the amount of frame dropout 
increased slightly; the type of under-run seen in 
the first scenario (after the termination of the 
client) occurred more frequently. This behav¬ 
ior was exhibited in both the first and second 
period and buffer size configurations for the 01 
and 03 optimisations. In the case of the 02 op¬ 
timisation, this behavior was not observed; in¬ 
stead a severe under-run issue occurred during 
the second period and buffer size configurations 
whereby the server immediately began to under- 
run before the client had even been launched. 
In relation to the third scenario, similar types 
of under-run behavior were seen as in the previ¬ 
ous two scenarios whereby under-runs occurred 
after the termination of the client. No frame 
dropouts were observed for the 02 optimisation 
for this particular scenario. 

6 Conclusion 

Throughout this paper we presented a study 
aimed at evaluating the responsiveness of a 
Linux embedded system. As part of a larger 
study on DMIs design, we focused on test¬ 
ing latency and quality of audio output on a 
BeagleBone Black board running the standard 
Angstrom distribution with no kernel modifi¬ 
cations. Two different audio backend systems 
were taken into consideration, one based on 
ALSA, the other on JACK, and measurements 
using a USB audio interface and an Audio Cape 
were compared. The test monitored event-to- 
audio latency and included the monitoring of 
under-run activity. 

Data analysis showed for both ALSA and 
JACK audio systems remarkably low latency 
values, especially for small buffer and period 
size configurations. In particular, the use of the 
Audio Cape allows for latency values lower than 
3ms. In some of the different CPU scenarios 
taken into consideration the audio stream pre- 



sented dropouts and clicks, especially when us¬ 
ing small buffer and period size configurations. 
However, the usage of the different levels of code 
optimisation available in the chosen compiler 
(cross-Gcc 01, 02 and 03) completely fixed the 
audio quality in most of the tested configura¬ 
tions. 

No previous works delved into the audio capa¬ 
bilities of the BeagleBone Black while running 
the default Linux distribution (Angstrom with 
kernel 3.8). Compared to other distributions, 
like Ubuntu or Fedora, the usage of Angstrom 
on the BeagleBone Black proved to support very 
low latency configurations without the need of 
a customised kernel. In the context of digital 
musical instrument design, this feature is re¬ 
markable and makes the BeagleBone Black an 
appealing platform for instrument development. 
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